@device(LPT)
@libraryfile(dictionary)

@Comment{
			***** NOTE *****
	 THE MOST CURRENT FILE IS [SCORE]<CSD.MRS.MANUAL>REPN.MSS;
   It is the SAIL file which is unofficial, and not necessarily up to date!!!

Many of the things here (perhaps) belong elsewhere -- they
have been so tagged.
REPN and (maybe) REPN-METHOD go into Meta-Vocabulary;
Representation should go into some general concept area
	(joined there be things like Inference, Inheritance, ...)
and who knows where
Property List and Discrimination Net go (in general concept?)

CHARACT-FN and ARITY is included only because they were mentioned
in some other description.

---
How should we refer to other "slots" of a given entry 
-- as facets, or slots, or ...?
---

This file points to RPNPRC.MSS, which has the actual procedures.
⎇
@Heading(Representation Methods)
@Comment[This should be a Section of the Internals chapter.]

The MRS user can use any of a number of representations to store and
retrieve his domain facts.
It is this ability,
(of allowing different facts to be encoded in different representations,)
which permits MRS to be arbitrarily efficient,
and still retain its generality.

While the user can construct his own representations,
MRS come equipped with a number of "built-in" ones.
This section describes many of these representations,
including not only the pertanent lisp procedures
but relevant definitions and conventions as well.

@COMMENT[Tom - what goes here?
Is the following pointer part appropriate? 
What about the section overview? ]

Readers unfamiliar with the term "representation" are referred to
the entry @MRSREF[Representation].
Relevant entries, in this and other sections, include:
@BEGIN[ITEMIZE]
@MRSREF[REPN], which describes how one can declare which representation
to use for a (class of) proposition(s).
(This points to entries @MRSREF[REPN-METHOD],
@MRSREF[DOMAIN] and @MRSREF[OPDOMAIN].)

@MRSREF[Representation Naming Strategy] describes how to "decode" the
name of a representation, to understand roughly what it does.

@MRSREF[Discrimination Net] and @MRSREF[Property List]
describe two representation schemes,
which are employed by various pre-loaded representations.
@END[ITEMIZE]

The section begins with a general description of terms, like
@B[Representation], @B[Representation Naming Stategy], 
@B[Discrimination Net], and @B[Property List]. 
This is followed with a list of the particular representations included.
The penultimate list describes the vocabulary used to
associate a representation with a proposition.
Finally the various procedures which are used to implement these functions
are enumerated.

This section describes the
component methods of the default representation, @MRSREF[PDT],
in great detail.
To suppress needless duplication,
the descriptions of the other representations
(and their associated procedures) are more laconic --
usually only a description of how each differs from its
@B[PDT] correspondent is mentioned.

Every representation must supply the machinery necessary
to store, remove and retrieve facts.
MRS uses a particular set of procedures to span these functionalities.
The remainder of this introduction will describe
these MRS specific procedures --
in particular how the relate to one another.

Associated with each representation, @i<repn>,
are a number of procedures which peform the various functions --
@T[@i<repn>-STASH], @T[@i<repn>-UNSTASH], and @T[@i<repn>-INDB]
are the primary ones.
(The @MRSREF[REPN-METHOD] entry describes this "procedure to function" association.)
After performing a @T[(@i<repn>-STASH <ps>)] command,
@T[(@i<repn>-INDB <ps>)] will return @T[(T)] (possibly augmented with
a binding list, depending on the free variables within the propositional
symbol <ps>).⎇

A subsequent @T[(@i<repn>-UNSTASH <ps>)] command will undo that stash,
in that @T[(@i<repn>-INDB <ps>)] will then return @T[NIL].
(The interactions part of the entry @MRSREF[PDT] further elaborates this point.)

The other functions deal with various flavors of retrieval,
all taking the same single argument @T[@i<repn>-INDB] expects,
a proposition symbol, <ps>.
and return a list of binding lists,
which each correspond to some acceptable proposition, P, present in the
currently active data base.
@T[@i<repn>-INDB] is the simplest:
it simply checks if this same <ps> is in the data base,
insisting this match be identical up to variable names,
but will perform no other matchings.
(See @MRSREF[Same Proposition].)
@T[@i<repn>-LOOKUP] is more complicated --
when attempting to match <ps> to some P,
it will attempt to instantiate the free variables in <ps> to terms embedded in P.
Unlike @T[@i<repn>-ULOOKUP],
@T[@i<repn>-LOOKUP] will not match the other way: 
it will not consider binding the variables found in P to <ps>'s ground terms.
@T[@i<repn>-ULOOKUP] is most general,
accepting any proposition in the currently active 
data base which unifies with <ps>.

A quick example:
Assume that the proposition @T[(Father $X Odin)] is in the data base.
Then @T[(@i<repn>-INDB ↑(Father $Y Odin))] => @T[((T ($Y . $X)))]@FOOT[
Two notes:
First, "@T[<form>] => @T[<expr>]" means that evaluating this @T[<form>] form 
will return the expressin @T[<expr>].
Second, this use of @T<↑> follows the convention defined in @MRSREF<↑>.
Realize that this cannot be legally enterred.]
but @T[(@i<repn>-INDB ↑(Father $Y $Z))] => @T[NIL].
The next more complex @T[@i<repn>-LOOKUP] procedure returns
the same result @T[@i<repn>-INDB] does, 
whenever @T[@i<repn>-INDB] returns non@T[NIL].
In addition,
@T[(@i<repn>-LOOKUP ↑(Father $Y $Z))] => @T[((T ($Y . $Z) ($Z . Odin)))].
@T[@i<repn>-ULOOKUP] is even more general:
@T[(@i<repn>-ULOOKUP ↑(Father George $Z))] => 
@T[((T ($Z . Odin)))],
while
@T[(@i<repn>-LOOKUP '(Father George $Z) 1)] => @T[NIL].

NOTE: @T[@i<repn>-ULOOKUP] 
may one day return both directions of bindings -- i.e.
@T[(@i<repn>-ULOOKUP ↑(Father George $Z))] =>
@T[((T (George . $Y) ($Z . Odin)))].

Each of these query procedures should really be regarded as a generator,
which can be used to return to return as many binding lists as desired.

The only remaining lisp procedure is @T[@i<repn>-LOOKUPVAL],
whose only argument is a term symbol.
This returns (one or more) values of that expression.
Hence @T[@i<repn>-LOOKUPVAL ↑(Father Mary)] should return @T[Fred] when
@T[@i<repn>-LOOKUP ↑(Father Mary $X)] would have returned @T[(T ($X . Fred))].

While each representation is expected to supply
methods for the primary functions,
(@T[STASH], @T[UNSTASH], and @T[INDB]),
not all will have methods associated with each of the secondary functions
listed above.

@HBAR()
@BEGIN[MRSEntry]@Name(Representation)
@Brief[(Concept of) Mechanisms for storing and retrieving facts.]

@Comment[ @Usage{N/A⎇ ]

@Type(General Concept)

@Descript{
The term @i[representation] refers to the mechanisms used to
store and retrieve a fact or collection of facts.
For example, consider the assertion that
"the father of Mary is Fred".
Using a property list representation one would store this fact
by filling the Father property of the atom Mary with the value Fred.
Here the basic storage mechanism is @T[PUTPROP], and the retrieval facility
is based on @T[GETPROP].
Another possible representation is a fully indexed discrimination net.
Each embedded term, (here: Father, Mary and Fred) 
would have a pointer to each including propositions --
the proposition @i[(Father Mary Fred)] in this case.@FOOT[
The discrimination net used by representations like @MRSREF<PDT>
is not fully indexed.]

@COMMENT[Should I use GETPR and PUTPR, to be COMMON-lisp-y?]

Each representation has its own advantages and disadvantages.
Storage is quite fast using the property list representation,
but that scheme can only handle certain types of facts 
(those which can be encoded as binary relations),
and the only fast way to access (and hence retrieve) a fact is via is
second argument.
While the fully indexed discrimination net approach is slower for storage, 
(as it needs to link each embedded term with the full proposition,)
it can accomodate more types of facts,
and
(by the use of effective hashing procedures,)
the time required to retrieve a fact can be independent
of the size of the data base.

Realizing these tradeoffs, MRS permits its users to specify how
any particular fact
(or group of facts)
should be handled.
Using MRS assertions (see @MRSREF[REPN],)
the user can indicate which representation to use for each type of fact.
This allows different facts to be encoded in different representations.
⎇

@SeeAlso[@MRSREF{REPN⎇,
@MRSREF{Representation Naming Strategy⎇,
@MRSREF{$stash⎇, @MRSREF{$unstash⎇, @MRSREF{$lookupn⎇]

@Warnings{
The issue of representation is orthogonal to inferencing.
(See @MRSREF[Inference].)
That is, we are discussing how to retrieve a fact,
not how to determine whether is true.
(This is the basis of LOOKUP/TRUEP dichotomy --
elaborated in the @i[Examples] part below.)
⎇

@Comment[ @Diagnostics{N/A⎇ ]

@History(RDG, 9 September 1982, created)

@Interactions{ (N/A) ⎇

@Examples{
The representation itself is expected only to perform
straight-forward lookups, not deductions.
To elucidate this point,
consider "the father of Mary is Fred" fact, mentioned above.
Imagine now that we had used property lists to store the facts that
@T[(Mother Mary Jane)] and @T[(Husband Jane Fred)],
but not @T[(Father Mary Fred)]
While we could @i[deduce] that Mary's father was Fred,
that fact is not explicit in this representation;
we could NOT simply look it up.
Hence @T[($lookup '(Father Mary Fred))] should return @T[NIL].
@T[$truep], on the other hand, is permited to perform deductions,
meaning that,
given the appropriate inference procedures,
@T[($truep '(Father Mary Fred))] could return @T[(T)].
@Comment[Perhaps I should use the map example also
-- it represents distances, not ...]
⎇

@Comment[ @sourcefile(N/A) ]

@keywords(@MRSIndex[store], @MRSIndex[retrieve],
@MRSIndex[efficiency], @MRSIndex[encode])
@END[MRSEntry]
@BEGIN[MRSEntry]@Name(Representation Naming Strategy)
@Brief(Naming convention for initial MRS representations)

@Usage{@i[___]-<operation>, where <operation> may be
STASH, UNSTASH, INDB, LOOKUP, ULOOKUP, LOOKUPVAL⎇

@Type(General Concept)

@Descript{
This strategy is used to encode a description of 
each MRS representation within its name.
These names, in turn, are used as the prefices of the associated 
lisp procedure methods.⎇

@BEGIN[MRSSlotcontinued]
Given the task of storing and retrieving a proposition,
there are three major things to consider;
@+[(1)]the indexing mechanism, 
@+[(2)]in what type of data structure the fact is stored,
and 
@+[(3)]how this data structure is associated with the theory structure.
Each of these attributed is encoded by 
a letter (or absense of a letter)
@Comment[ complain to DE2 about this! ]
in the name of the representation.

The first issue relates to the question of how to locate a given 
propositional expression, P.
This address is needed both when retrieving P,
and to determine where to store it.
One can use this P as an index,
pointing to the propositional symbol, 
(and from that facts about P itself).
Representations using this indexing scheme have the letter "P"
in the first character position.
In the "C__" class of representations
each proposition will point to a list of its superclauses.
Stated another way,
each subclause of the proposition, P, will point to P's symbol.
"A__" means each atom will point to each containing proposition.

For example,
consider how to locate the proposition
@T[(IF (AND (LARGE $X) (GRAY $X)) (ELEPHANT $X))],
whose canonical (propositional) symbol is @T[Rule7].
Each "P__" representations
will have a pointer associated with the full proposition,
@T[(IF (AND (LARGE $X) (GRAY $X)) (ELEPHANT $X))],
which leads to this @T[Rule7].
(Recall that the propositional symbol, @T[Rule7], will in turn,
lead to facts about the propositional expression
@T[(IF (AND (LARGE $X) (GRAY $X)) (ELEPHANT $X))].)
In the "C__" family of representations,
not only will this full clause point to @T[Rule7], 
but so will each of its subclauses, like 
@T[(AND (LARGE $X) (GRAY $X))], @T[(ELEPHANT $X)],
@T[(LARGE $X)] and @T[(GRAY $X)].
In yet other cases each atomic symbol, here
@T[LARGE], @T[GRAY], and @T[ELEPHANT],
(and possibly from logical symbols like @T[IF], @T[AND], and @T[$X] as well)
will point to the full proposition -- these are "A__" representations.

Two other mechanism have been defined,
both related to the property list data structure.
These two are "S", (for "@i[s]ingle property list") and
"M", (as in "@i[m]ultiple-valued property list").
(See @MRSREF[Property List], @MRSREF[SP] and @MRSREF[MP].)

The second consideration pertains to the data structure in which
the proposition will actually be stored --
within a discrimination net, or a property list, or perhaps in a bit table, etc.
The currently defined second letters include
"D", meaning the proposition symbol is stored in a @T[D]iscrimination Net,
and
"P", meaning the proposition is encoded within a @T[P]roperty List.

The third (possibly omitted) 
@Comment[Again I accept none of the blame]
letter specifies how this data structure is stored.
It may be "G" or "T", or may be omitted.
Each propositions stored in a "__G" representation is housed in a global structure,
and is "tagged" with a list of all theories in which it is included.
If the third letter is "T" then facts in different theories will be stored in
different data structures 
(where each different data structure associated with a different theory).
Finally, omitting this letter
means that facts stored in this representation are not
associated with any theory --
usually this means this proposition is outside of MRS.
@END[MRSSlotcontinued]

@SeeAlso[@MRSREF{REPN⎇, @MRSREF{Representation⎇, @MRSREF{Theories⎇,
@MRSREF{PDT⎇, @MRSREF{PDG⎇, @MRSREF{PD⎇, @MRSREF{SP⎇ and @MRSREF{MP⎇]

@Warnings{
This scheme is not exhaustive;
there are many other dimensions along which representations may vary.
Hence it is possible to build two different representations which would
have the same name under this scheme.

Other dimensions include
@BEGIN[ITEMIZE]
Whether all of the facts (associated with a theory, in this representation)
are contained in a single data structure.
[If so, commands like dumps and contents will be fast.]

What is actually stored.
In some cases, a propositional symbol is stored; while others would store 
only the propositional expression.

There are other possible theory dependency schemes.
For example, one may want to associate all facts with a particular theory,
independent of the current theory.

Whether duplicates are permitted.
@END[ITEMIZE]
⎇

@Comment[ @Diagnostics{N/A⎇ ]

@History(RDG, 20 September 1982, created)

@Comment[ @Interactions{N/A⎇ ]

@Examples{
The name of the PDT representation ("PDT" of course) encodes the facts that
@+[(1)]a propositional symbol is indexed using
only its full @T[P]roposition expression,
@+[(2)]such facts are store within a @T[D]iscrimination Net,
and
@+[(3)] each @T[T]heory will have its structure for storing its facts.
(See the @MRSREF[PDT].)
⎇

@Sourcefile(PREP.CL)

@keywords(@MRSIndex[naming convention], @MRSIndex[representation])
@END[MRSEntry]
@BEGIN[MRSEntry]@Name(Discrimination Net)
@Brief(Data structure used to store and retrieve general propositions,
after commoning prefixes.)

@Usage{@T[_D_] in name of a representation⎇

@Type(General Concept)

@Descript{
Representations based on this data structure
can be used to store any S-expression.
(In the common prefix discrimination nets we will discuss)
retrieval is based on a token by token sequential search down
this tree structure,
which has commoned identical prefix.
See @Cite[Charniak].

The discrimination net used is a tree structure whose internal nodes
represent atomic terms, (such as @T[Father], or @T[(],)
and whose leaf nodes store the full S-expression which has just been
traversed -- e.g. @T[(Father Mary Fred)].
Each "descendent" link connects a term to a term which succeeds it in
some stored propostion.
The example given below should further clarify this description.
⎇

@SeeAlso[@MRSREF{PDT⎇, @MRSREF{PDG⎇, @MRSREF{PD⎇,
@MRSREF{Representation⎇, @MRSREF{Representation Naming Strategy⎇]

@Warnings{
As implemented,
a given proposition will appear only once within
any particular discrimination net.
This means that the presense of one proposition, P', may prevent
an equivalent proposition, P,
(see @MRSREF[Same Proposition],)
from actually being stashed.
If P' is housed in the same data structure
(which means is associated with the same theory in @B[PDT]'s case,
or in the single global structre for @B[PDG],)
@T[($stash P)] will NOT store this copy of P.
(Of course this says nothing about the effects of this stash when
this P' is present elsewhere --
i.e., if it is in stored in some other representation associated with
the P's theory,
or in (any representation of) any other (active) theory.
We assume it will be (re)stashed in these cases.)
⎇

@Comment[ @Diagnostics{N/A⎇ ]

@History(
RDG, 9 September 1982, created)

@Comment{ Should I include a "Knuth Vol ?" type citation? ⎇

@Comment[ @Interactions{N/A⎇ ]

@Examples{
First, notice that any representation whose name is of the form "_D_" uses a
discrimination net
-- @MRSREF[PDT], @MRSREF[PDG] and @MRSREF[PD] in the current implementation.⎇

@BEGIN[MRSSlotContinued]
Secondly, we present an example to show how this indexing mechanism is used.
Consider searching this (type of) discrimination net for
the proposition @T[(Father Mary Fred)].
This corresponds to finding a particular path through this discrimination net tree;
one which starts from the root,
and terminates with a leaf node whose "value" is the proposition
@T[(Father Mary Fred)].@FOOT[
Different representations may store other things there as well.
For example, in the @T<CDT> representation, this leaf node would
include each proposition in which this clause occurs -- e.g.
@T<(AND (Mother Mary Francine) (Father Mary Fred))> as well as
@T<(Father Mary Fred)>.   Here is also
where the representation
can store the theories in which this assertion has been stored.]
This is achieved by passing through nodes which are labelled
with the tokens in this expression in order:
@T[$ROOT$ $OPEN-PAREN$ Father Mary Fred $CLOSE-PAREN$]@FOOT[
The real names in the code are slightly different -- 
e.g. @T<$BEGIN$> for @T<$OPEN-PAREN$> and @T<$END$> for @T<$CLOSE-PAREN$>.]
One reaching a leaf node, its value is compared with the sought expression.
(For subtle reasons 
the same path may have referred to several different propositions
-- e.g. the same leaf could refer to both
@T[(EQUAL $X $X)] and @T[(EQUAL $X $Y)].)

The expression @T[(Father Anne George)] uses the same first three nodes,
(@T[$ROOT$], @T[$OPEN-PAREN$] and @T[Father])
splitting off at the @T[Mary] node,
chosing here the subtree whose head node is labelled @T[Anne] rather than @T[Mary].

Storage works the obvious way:
The stasher walks along the propositional expression while descending the tree,
trying at each stage to match the current token from the expression with
the label of one of the current collection of subtrees.
(The labels of the subtrees under each node are stored in a hash table.)
If none of the labels match, a new subtree is sprouted, 
and inserted under the current node.

There remain a number of remaining nuances,
which deal with things like variables.
Ask AF for futher details.
@END[MRSSlotContinued]

@Comment[ @sourcefile(N/A) ]

@keywords(@MRSIndex[representation], @MRSIndex[retrieve],
@MRSIndex[storage], @MRSIndex[discriminate], @MRSIndex[index], @MRSIndex[tree])
@END[MRSEntry]
@BEGIN[MRSEntry]@Name(Property List)
@Brief(Storing binary propositions as Property/Atom/Value triples.)

@Usage{@T[_P_] in name of a representation⎇

@Type(General Concept)

@Descript{
Representations based on this data structure
can be used to store any binary fact. 
(See @MRSREF[Arity of Proposition].)
Two familiar examples are
the Unit/Slot/Value (frame) contruct
described in @Cite[Frames-Minsky],
and the LISP property list facility.
(In the latter system,)
a fact like @T[(Father Mary Fred)] could be encoded by storing
the value Fred on the Father (property list) property of the atom
Mary.@FOOT[
Which means, as any LISP user knows, the value of @T[(PLIST 'Mary)]
will be of the form 
@T<(p@-<1> v@-<1> ... p@-<N> v@-<N>)>,
where some @T<p@-<i>> equals @T<Father>,
and the value of the corresponding
@T<a@-<i>> is @T<Fred>.]

Hence indexing a fact of the form
@T[(Slot Unit Value)] involves retrieving the
@T[Slot] property of the atom @T[Unit].
Note that there is no inherent semantic associated with the value returned by
@T[(GETPR Unit Slot)].
This permits us to store things like
@T[(Menlo-Park Mountain-View Los-Altos)] on the @T[Neighbors] property
of the atom @T[Palo-Alto], 
(and mean the obvious thing,)
even though the "assertion"
@T[(Neighbors Palo-Alto (Menlo-Park Mountain-View Los-Altos))]
is syntactically ill-formed.
⎇

@SeeAlso[@MRSREF{SP⎇, @MRSREF{MP⎇,
@MRSREF{Representation⎇, @MRSREF{Representation Naming Strategy⎇]

@Warnings{
First, this will only work (easily) for binary relations 
-- i.e. facts of the form (Property Object Value).
(There are mechanisms for (awkwardly) encoding
non-binary propositions using this data structure.  See @Cite[Nilsson-2].)⎇

@BEGIN[MRSSlotcontinued]
Furthermore, there are several restrictions on
the second argument, (Object above,) both for storage and retrieval.
It must be a ground atom --
eliminating both general terms, like @T[(Resistance (Output 3))],
and variables, like @T[$X].

The second major problem is that property lists are good for
(unary) @i[functions], but not (binary) @i[relations].
This leads to the "overwriting" problem,
associated with (though not inherent in) property lists:
Imagine we have stored the fact that @T[(Neighbor Palo-Alto Menlo-Park)],
in the straightforward way, by inserting the value
@T[Menlo-Park] on the @T[Neighbor] property of @T[Palo-Alto].
All well and good.
Now we wish to assert that
@T[(Neighbor Palo-Alto Mountain-View)].
Simply storing @T[Mountain-View] on the 
@T[Neighbor] property of @T[Palo-Alto] wouldn't do 
-- that would clobber the @T[Menlo-Park] value already there.
(This problem is not unsolvable:
the @MRSREF[MP] scheme was designed to handle this situation.
Another solution would involve having a number of @T[Neighbor] properties,
each filled with a different value.  There are, however, limitations with
each of these approaches.)

A third problem is how to retrieve facts. 
Since the only cheap way to access a fact is via its second argument,
storing @T[(Father Mary Fred)] will be useful for figuring
who is Mary's father, but not who are Fred's children.
That would require storing a (technically redundant) back-pointer, of the
form @T[(Child Fred Mary)].
@END[MRSSlotcontinued]

@Comment[ @Diagnostics{N/A⎇ ]

@History(RDG, 14 September 1982, created)

@Comment[ @Interactions{N/A⎇ ]

@Examples{
Any representation whose name is of the form "_P_" uses a property list
-- @MRSREF[SP] and @MRSREF[MP] in the current implementation.⎇

@Comment[ @sourcefile(N/A) ]

@keywords(@MRSIndex[representation], @MRSIndex[retrieve],
@MRSIndex[storage], @MRSIndex[index])
@END[MRSEntry]

@BEGIN[MRSEntry]@Name(REPN)
--- This goes into Meta Vocabulary ---
@Brief(Associates a class of propositions with a representation.)

@Usage{@T[(REPN] <prop-sym> <rep'n>@T[)]⎇

@Type(Function Symbol)

@Descript{
This asserts that
the representation <rep'n> will be used to represent
the propositional symbol <prop-sym>.
MRS uses this fact to declare which methods should be used to
stash, unstash and retrieve this <prop-sym>.

@T[REPN] uses the @T[REPN-METHOD] relation to actually build the appropriate
@T[MYTO] declaration;
this is described in the @T[REPN-METHOD] entry cited below.⎇

@SeeAlso{@MRSREF[Representation],
@MRSREF[REPN-METHOD], @MRSREF[MYTO]⎇

@Warnings{
First, it is important to @T[$assert] the @T[(REPN ...)] statements,
rather than simply @T[$stash] them.  
It is the forward inference associated with the @T[REPN] relation
which actually ties the proposition with the relevant methods,
not the stored @T[(REPN ...)] statement.@FOOT<
Allowing the effects of the @T[(REPN ...)] statements to work in a backwards
chaining fashion can easily lead to infinite loops, 
as well as (other) inefficiencies.>

The second issues is subtler:
even though @T[REPN] is a function,
there are (currently) no checks to insure that it is, indeed, single valued.
Hence, one can assert that @T[(REPN (PROP ↑Color $A $C) SP)],
even if the (now-incompatible)
@T[(REPN (PROP ↑Color $A $C) PDT)] is present in the system.
At this point the method used to store @T[(Color Frog7 Green)] 
is not well defined
-- whether it will use the PDT scheme, or the newer SP system.
(This check could get arbitrarily complicated: imagine adding something like 
@T[(REPN (PROP $Relation $A ↑Green) SP)] rather than
@T[(REPN (PROP ↑Color $A $C) SP)]...)

A related issue, knowledge base consistency, also arises when a
proposition is declared to be of a different representation:
MRS does NOT go through all current assertions which were stored in that format,
and re-stash them into the new representation.
⎇

@Diagnostics{This assertion should always return non@T[NIL].
Otherwise there was some error in the stashing/forward-inferencing process,
and this new assertion may not "take effect".⎇

@History(RDG, 14 September 1982, created)

@Interactions{
The effects of a @T[(REPN <prop-sym> <rep'n>)] depend intimately on the
stored propositions of the form
@T[(REPN-METHOD <rep'n> <operation> <method>)], (for this same @T[<rep'n>],)
and indirectly on the @T[(OPDOMAIN <operation> ...)] propositions.
The @MRSREF[REPN-METHOD] entry spells this out in detail.⎇

@Examples{
After asserting @T[(REPN (PROP ↑Color $A $C) SP)],
every subsequent assertion of the form @T[(Color <obj> <color>)] will be
stored using the @T[SP] representation,
i.e. on the @T[Color] property of the @T[<obj>] atom.
Prior to that declaration,
(in a vanilla MRS system,)
these same propostitions would have been stored in the 
default @T[PDT] representation 
-- i.e. in a theory dependent discrimination net.⎇

@sourcefile(? REPN ask Andy ?)

@keywords(@MRSIndex[representation], @MRSIndex[method])
@END[MRSEntry]
@BEGIN[MRSEntry]@Name(REPN-METHOD)
--- This goes into Vocabulary ---
@Brief(Associates a method with an operation, for a particular representation.)

@Usage{@T[(REPN-METHOD] <rep'n> <operation> <method>@T[)]⎇

@Type(Function Symbol)

@Descript{
This asserts that the representation <rep'n> will use the 
<method> lisp procedure to perform the <operation> operation.
This is, in turn, used by the (functions dealing with the) @T[REPN] relation
to build appropriate @T[MYTO] relations for the involved proposition.

That is, given @T[(REPN-METHOD <rep'n> <operation> <method>)],
asserting @T[(REPN <prop-sym> <rep'n>)] 
will cause MRS to assert @T[(MYTO <operation> <prop-sym> <method>)],
for each <operation> of the correct type 
-- those whose only argument is declared to be a proposition symbol, 
using @T[OPDOMAIN].
It will also generate an appropriate @T[MYTO] declaration when this
<operation> takes a term symbol for its argument.
(The @i[Examples] facet below works through an example of this.)

To cover other representation dependent operations
like @T[CONTENTS] or @T[FACTS],
@T[REPN-METHOD] can also deal with operations whose argument is a 
general symbol, or a theory.
⎇

@SeeAlso[@MRSREF{Representation⎇,
@MRSREF{REPN⎇, @MRSREF{OPDOMAIN⎇, @MRSREF{METHOD⎇, @MRSREF{MYTO⎇]

@Warnings{
This assertion was intended only for representation related functions.
It is, therefore, most meaningful for <operation>s
whose first argument is a proposition symbol,
but can also be used to deal with representation functions whose
first argument is term, symbol or theory.
(@MRSREF[OPDOMAIN] describes how to declare the typing for the
arguments of an operation.)

This covers all of the current representation related functions. 
As this collection of functions is open-ended,
we are not restricting
@T[REPN-METHOD] declarations to only this class of functions.
Of course such assertions would now be "meaningless",
in that we have not implemented any procedures to use such information.
⎇

@Comment[ @Diagnostics{N/A⎇ ]

@History(RDG, 14 September 1982, created)

@Interactions{
@T[REPN] assertions use @T[REPN-METHOD] declarations to
generate the appropriate @T[MYTO] assertions.

Note that vanilla MRS contains the assertion that
@T[(DEFAULT (REPN $P PDT))].
⎇

@Examples{
Suppose that @T[(REPN-METHOD PDG STASH pdg-stash)] and
@T[REPN-METHOD PDT LOOKUPVAL pdt-lookupval] have beeen declared.
Then the assertion
@T[(REPN (PROP ↑LOVES $X $Y) PDG)] will mean that 
all propositions which match 
@T[(LOVES $X $Y)] will be stashed using @T[pdg-stash].
That is, 
@T[($stash '(LOVES George Mary))] will result in
@T[(pdg-stash ↑(LOVES George Mary))].
It will also mean that every @T[LOOKUPVAL] call whose term symbol
is of the form @T[(LOVES <sym>)] will go through @T[pdt-lookupval] --
hence @T[($lookupval '(LOVES George))] will result in
@T[(pdt-lookupval ↑(LOVES George))], returning @T[Mary].

For these to work, both
@T[(OPDOMAIN STASH 1 PROP-SYMBOL)] and
@T[(OPDOMAIN LOOKUPVAL 1 TERM-SYMBOL)] (respectively)
must be present, which is true in the starting system.
See @MRSREF[OPDOMAIN].
⎇

@sourcefile(MRS?)

@keywords(@MRSIndex[representation], @MRSIndex[method], @MRSIndex[operation])
@END[MRSEntry]
@BEGIN[MRSEntry]@Name(OPDOMAIN)
--- This goes into Vocabulary ---
@Brief(Declares the types of an operation.)

@Usage{@T[(OPDOMAIN] <operation> <index> <predicate>@T[)]⎇

@Type(Function Symbol)

@Descript{
This asserts that the <index>@+[th] argument of the <operation> operation
will satisfy the predicate <predicate>.
This is defined for each integer <index>,
ranging from @T[1] through the arity of the operation.
It, along with @T[REPN-METHOD], 
is used by @T[REPN] to find the relevant operation/method pairs.

The procedure call @T[(<operation> ... <arg@-<index>> ...)]
should be an error unless this @T[<index>]@+[th] argument,
@T[<arg@-<index>>], satisfies the predicate @T[<predicate>] --
i.e. unless @T[(<predicate> <arg@-<index>>)] is true.
(Of course there is  one such type check for each argument.)

This @T[OPDOMAIN] relation for operations performs the same function
@T[DOMAIN] does for relations.
⎇

@SeeAlso[@MRSREF{Predicates⎇, @MRSREF{Operation⎇,
@MRSREF{ARITY⎇, @MRSREF{DOMAIN⎇]

@Warnings{
These @T[OPDOMAIN] assertions are
not used for type checking (as MRS currently (14 Sept 82) performs no such checks).
In fact, the only operations which use this information are 
those procedures associated with the @T[REPN] relation.

There are many obvious limitations to this typing system.
First, there is no easy way to deal with operations which handle an arbitrary
number of arguments, such as @T[+] or @T[AND].
Second, there is no easy way to encode any interdependencies among
the arguments.
(E.g. the final argument of the @T[+] operation will satisfy
the @T[REAL] predicate if any of
the earlier arguments was of this type, otherwise the appropriate
predicate is @T[INTEGER].
Third, it presupposes the existence of a variety of types.
(The current system knows about
SET,
RELATION, <<< meaningful? or just RELNSYMBOL >>>
FUNCTION,
PREDICATE, PROPOSITION, TERM,
PROPEXPR, <<<is this PROPOSITION ?>>>
FUNEXPR, <<<is this TERM ?>>>
RELNSYMBOL, <<<is this RELATIONSYMBOL ?>>>
FUNSYMBOL,
PROP-SYMBOL, TERM-SYMBOL, THEORY,
INTEGER, REAL, and the most general, THING ... <<and what else>>)

Eventually we will build a more general scheme,
which can more readily handle optional parameters,
inter-relationships of the arguments,
ability to have different types for
the same relation symbol, (depending on the arity of its use,) etc.
⎇

@Comment[ @Diagnostics{N/A⎇ ]

@History(RDG, 14 September 1982, created)

@Interactions{
(none)
⎇

@Examples{
The proposition @T[(OPDOMAIN STASH 1 PROP-SYMBOL)]  means that
the first argument to the STASH operation is a proposition symbol.
For comparison,
@T[(OPDOMAIN LOOKUPVAL 1 TERM-SYMBOL)] means that
the first argument of the @T[LOOKUPVAL] procedure is a term symbol.
⎇

@sourcefile(MRS?)

@keywords(@MRSIndex[type checking], @MRSIndex[operation],
@MRSIndex[range], @MRSIndex[specification])
@END[MRSEntry]
@BEGIN[MRSEntry]@Name(DOMAIN)
--- This goes into Vocabulary ---
@Brief(Declares the types of a relation.)

@Usage{@T[(DOMAIN] <relation> <index> <predicate>@T[)]⎇

@Type(Function Symbol)

@Descript{
This (second order) assertion 
means that the <index>@+[th] argument of the <relation> relation will satisfy
the predicate <predicate>.
This is defined for each integer <index>,
ranging from @T[1] through the arity of the relation.

The clause @T[(<relation> ... <arg@-<index>> ...)]
will only be (type-wise) meaningful
if this @T[<index>]@+[th] argument,
@T[<arg@-<index>>], satisfies the predicate @T[<predicate>] --
i.e. if 
@T[(<predicate> <arg@-<index>>)] is true.
(Of course there is  one such type check for each argument.)

This @T[DOMAIN] relation is closely related to the @T[OPDOMAIN] relation;
the only difference is that
the first argument of the @T[OPDOMAIN] relation is an operation rather than
a relation.

This system could later be expanded to form the basis of a type checking
system.
⎇

@SeeAlso[@MRSREF{Predicates⎇, @MRSREF{Relation⎇,
@MRSREF{ARITY⎇, @MRSREF{OPDOMAIN⎇,
@MRSREF{REPN⎇, @MRSREF{REPN-METHOD⎇]

@Warnings{
These @T[DOMAIN] assertions are
not used for type checking (as MRS currently (14 Sept 82) performs no such checks).
The limitations mentioned in describing @MRSREF[OPDOMAIN] apply here as well.
⎇

@Comment[ @Diagnostics{N/A⎇ ]

@History(RDG, 14 September 1982, created)

@Interactions{
(none)
⎇

@Examples{
The proposition @T[(DOMAIN FATHER 1 PERSON)]  means that
the first argument to the @T[FATHER] relation should be a person.
Another (self-referencing) example is
@T[(DOMAIN DOMAIN 1 RELATION-SYMBOL)], which means that
the first argument to the @T[DOMAIN] relation is a relation.
(For comparison, not that @T[(DOMAIN OPDOMAIN 1 OPERATION)].)
@T[(DOMAIN DOMAIN 2 INTEGER)] and
@T[(DOMAIN DOMAIN 3 PREDICATE-SYMBOLS)]
mean that the second and third arguments of @T[DOMAIN]
are an integer and a predicate, respectively.
⎇

@sourcefile(MRS?)

@keywords(@MRSIndex[type checking], @MRSIndex[relation],
@MRSIndex[range], @MRSIndex[specification])
@END[MRSEntry]
@BEGIN[MRSEntry]@Name(ARITY)
--- This goes into Vocabulary ---
@Brief(Specifies the number of arguments a relation or an operation takes.)

@Usage{@T[(ARITY] <relation> <integer>@T[)] or
@T[(ARITY] <operation> <integer>@T[)]⎇

@Type(Function Symbol)

@Descript{
This (second order) assertion
means that the relation <relation>
(or operation <operation>)
takes <integer> arguments.

This relation is currently not in use.
When type checking is performed,
it will be used to determine the well-formedness of each clause of an assertion.
⎇

@SeeAlso[@MRSREF{Relation⎇, @MRSREF{Operation⎇,
@MRSREF{DOMAIN⎇, @MRSREF{OPDOMAIN⎇]

@Warnings{
This @T[ARITY] function is not defined for all relations:
some relations, such as @T[+],
can take an arbitrary number of arguments.
Also, as this arity was designed for general relations,
its behavior with respect to functions may seem strange.
E.g. the  @T[(ARITY MINUS 3)], as the binary function @T[MINUS]
is a ternary relation.
⎇

@Comment[ @Diagnostics{N/A⎇ ]

@History(RDG, 14 September 1982, created)

@Interactions{
(none)
⎇

@Examples{
The proposition @T[(ARITY INDBN 3)] means that the @T[INDBN] relation
takes three arguments -- 
which (we can see from the @T[(DOMAIN INDBN <i> <type>)] declarations)
are a proposition, a integer and a binding list.
And, the expected, @T[(ARITY ARITY 2)].
⎇

@sourcefile(MRS?)

@keywords(@MRSIndex[type checking], @MRSIndex[range], @MRSIndex[specification])
@END[MRSEntry]
@BEGIN[MRSEntry]@Name(CHARACT-FN)
--- This goes into Vocabulary  -
@Brief(Associates a set with its characteristic function.)

@Usage{@T[(CHARACT-FN] <set> <procedure>@T[)]⎇

@Type(Function Symbol)

@Descript{
This asserts that the lisp procedure <procedure>
will return non@T[NIL] for all members of the set <set>,
and only for these members.
⎇

@SeeAlso[@MRSREF{Predicate⎇, @MRSREF{DOMAIN⎇, @MRSREF{OPDOMAIN⎇]

@Warnings{
Not all sets happen to have their respective characteristic function
defined in vanilla MRS.
⎇

@Comment[ @Diagnostics{N/A⎇ ]

@History(RDG, 14 September 1982, created)

@Interactions{
While this relation is currently not in use, when type checking is performed
these @T[CHARACT-FN] propositions will be used,
with @T[DOMAIN] and @T[OPDOMAIN],
to determine the well-formedness of each clause of an assertion,
and of the argument list of an operation.
⎇

@Examples{
The proposition @T[(CHARACT-FN INTEGER FIXP)] means that the
procedure @T[FIXP] will return @T[T] for every integer 
(well, for every integer LISP can hand it).

We have also asserted
@T[(CHARACT-FN RELATION-SYMBOL RELP)],
where the procedure @T[RELP] takes a single argument, and sees if that
symbol is a member of the class of @T[RELATION] -- i.e.
@T[(LAMBDA (R) (TRUEP `(MEM ,R RELATION)))].
⎇

@sourcefile(MRS?)

@keywords(@MRSIndex[type checking], @MRSIndex[set],
@MRSIndex[membership], @MRSIndex[specification])
@END[MRSEntry]
@BEGIN[MRSEntry]@Name(PDT)
@Brief(Theory dependent representation,
using a theory specific discrimination net, and
using proposition indexing.)

@Usage[@T{(⎇REPN <prop-sym> @T{PDT)⎇ or
@T{(PDT⎇-<rep'n fn> <prop-sym>@T{)⎇]

@Type(MRS Constant: Representation)

@Descript{
Any proposition which is associated with this @T[PDT] representation 
will use the PDT collection of representation methods --
@BEGIN[Example]
@T[pdt-stash] for stashing,
@T[pdt-unstash] for unstashing,
@T[pdt-lookupval] for term retrieval, and
@T[pdt-indb], @T[pdt-lookup] and @T[pdt-ulookup] for proposition retrieval.
@END[Example]
(The @MRSREF[REPN] entry describes how to associate a proposition
with a representation.)

Here, each theory has its own personal discrimination net.
These functions will store the proposition in the discrimination net
associated with the current @T[THEORY], indexed by the full proposition.
(See @MRSREF[Representation Naming Strategy].)

Notice this is NOT a fully indexed discrimination net --
hence it is relatively expensive to find all propositions will contain
a particular symbol, or specific clause.
(However there are@FOOT[well, will be]
ADT and CDT representations which will be more efficient at these tasks.)

The descriptions of the @MRSREF[PDG] and @MRSREF[PD] representations
compare the merits of this scheme with systems
which use a single global structure,
and which do not store theory dependences, respectively.

This is the default representation for propositions in the MRS system.

@Comment[Why is this the default?  Efficiency? Generality?
In particular, why isn't a fully indexed representational scheme used?]
⎇

@SeeAlso[
@MRSREF{REPN⎇, @MRSREF{Discrimination Net⎇, @MRSREF{Representation Naming Strategy⎇,
@MRSREF{pdt-stash⎇, @MRSREF{pdt-unstash⎇,
@MRSREF{pdt-indb⎇, @MRSREF{pdt-lookup⎇, @MRSREF{pdt-ulookup⎇,
@MRSREF{pdt-lookupval⎇
	@COMMENT< DE2 says NOT to include
		@MRSREF{pdt-ulookup1⎇, @MRSREF{pdt-ulookups⎇,
		@MRSREF{$pdt-stash⎇, @MRSREF{↑pdt-stash⎇, 
		@MRSREF{↑pdt-ulookup1⎇, @MRSREF{↑pdt-ulookups⎇ >
]

@Warnings{
The warnings given in @MRSREF[Discrimination Net] apply here.
⎇

@Comment[ @Diagnostics{N/A⎇ ]

@History(RDG, 9 September 1982, created)

@Interactions{
See the various connections described in @MRSREF[Representation].
These connect @T[pdt-stash], @T[pdt-unstash] and @T[pdt-indb];
and the retrieval methods 
@T[pdt-ulookup] and @T[pdt-lookup] with @T[pdt-indb];
and @T[pdt-lookupval] with @T[pdt-lookup].
⎇

@Examples{
Suppose @T[(LOVES George Mary)] is associated with the @T[PDT] representation.
Then the command @T[($stash '(LOVES George Mary))] will call
@T[(pdt-stash ↑(LOVES George Mary))], which will stash the proposition
@T[(LOVES George Mary)] in the discrimination net
associated with the current @T[THEORY].
Afterwards @T[($lookup '(LOVES George Mary))],
(which goes through @T[$lookupn] to @T[pdt-lookup],)
will return @T[(T)].
Similarly @T[($lookup '(LOVES George $X))] will return the binding list
@T[(T ($X . Mary))].  
These retrievals will only work if the theory active during the stash,
@T[THEORY], is still an active.
(They can also be fouled up by some intervening @T[pdt-unstash], 
or @T[pdt-stash], or theory deactivation, of course.)
⎇

@sourcefile(DREPN.CL)

@keywords(@MRSIndex[representation], @MRSIndex[discrimination net],
@MRSIndex[general structure], @MRSIndex[theory dependent]) 
@END[MRSEntry]
@BEGIN[MRSEntry]@Name(PDG)
@Brief(Theory dependent representation,
using a global discrimination net, and
using proposition indexing.)

@Usage[@T{(⎇REPN <prop-sym> @T{PDG)⎇ or
@T{(PDG⎇-<rep'n fn> <prop-sym>@T{)⎇]

@Type(MRS Constant: Representation)

@Descript{
Any proposition which is associated with this @T[PDG] representation 
will use the PDG collection of representation methods --
@BEGIN[Example]
@T[pdg-stash] for stashing,
@T[pdg-unstash] for unstashing,
@T[pdg-lookupval] for term retrieval, and
@T[pdg-indb], @T[pdg-lookup] and @T[pdg-ulookup] for proposition retrieval.
@END[Example]
(The @MRSREF[REPN] entry describes how to associate a proposition
with a representation.)

Here, there is a single, "master" discrimination net, which stores the facts 
asserted for all the theories.
These functions will store the proposition in that discrimination net,
(tagged with the theories in which it is stored),
indexed by the full proposition.
(See the @MRSREF[Representation Naming Strategy] entry.)

This representation is particularly
efficient when most of the 
available theories
(see @MRSREF[Available Theory])
are all active at any time.
Under these conditions,
PDG's storage time may be slightly slower than for PDT,
as this single general data structure will be larger than those 
associated with but a single theory.
However its retrieval can be considerably faster,
as one needs only read through a single data structure,
rather than one for each theory.
On the other hand, if only a few of the available theories are active,
PDT is a better choice.

If space is more relevant than time,
PDG's single data structure cannot help but be more storage efficient than
PDT's multiple nets.
⎇

@SeeAlso[
@MRSREF{REPN⎇, @MRSREF{Discrimination Net⎇, @MRSREF{Representation Naming Strategy⎇,
@MRSREF{pdg-stash⎇, @MRSREF{pdg-unstash⎇,
@MRSREF{pdg-indb⎇, @MRSREF{pdg-lookup⎇, @MRSREF{pdg-ulookup⎇,
@MRSREF{pdg-lookupval⎇]

@Warnings{
The warnings given for @MRSREF[Discrimination Net] apply here.⎇

@Comment[ @Diagnostics{N/A⎇ ]

@History(RDG, 14 September 1982, created)

@Interactions{
The various connections described in the @i[Interactions] part of @MRSREF[PDT]
apply here, @i[mutatis mutandis].
⎇

@Examples{
The example given for @MRSREF[PDT] works here, after substituting
@T[PDG] for @T[PDT], and using a single general discrimination
net, rather than a net associated only with the current theory.
⎇

@sourcefile(DREPN.CL)

@keywords(@MRSIndex[representation], @MRSIndex[discrimination net],
@MRSIndex[general structure], @MRSIndex[theory dependent]) 
@END[MRSEntry]
@BEGIN[MRSEntry]@Name(PD)
@Brief(Theory independent representation,
using a global discrimination net, and
using proposition indexing.)

@Usage[@T{(⎇REPN <prop-sym> @T{PD)⎇ or
@T{(PD⎇-<rep'n fn> <prop-sym>@T{)⎇]

@Type(MRS Constant: Representation)

@Descript{
Any <proposition> which is associated with this @T{PD⎇ representation 
will use the PD collection of representation methods --
@BEGIN[Example]
@T[PD-STASH] for stashing,
@T[PD-UNSTASH] for unstashing,
@T[PD-LOOKUPVAL] for term retrieval, and
@T[PD-INDB], @T[PD-LOOKUP] and @T[PD-ULOOKUP] for proposition retrieval.
@END[Example]
(The @MRSREF[REPN] entry describes how to associate a proposition
with a representation.)

As with the @T[PDG] representation,
here there is a single, "master" discrimination net,
which stores the facts asserted for all the theories.
These functions will store the proposition in that discrimination net,
however they will NOT be tagged with their associated theories.
(See the @MRSREF[Representation Naming Strategy] entry.)

This representation is particularly efficient for storing general purpose facts,
which should be accessible independent of which theory is currently active.
It terms of both storage and retrieval it will be more efficient than
either PDT or PDG, (in terms of both time and space)
as it will never have to consider the theory associated with a proposition.
It is, of course, less general than those representations,
as it cannot provide the theory-related manipulations which they permit --
i.e. facts stored using this @T[PD] cannot placed on specific theories,
and cannot be activated and deactived @i[en masse].
⎇

@SeeAlso[
@MRSREF{REPN⎇, @MRSREF{Discrimination Net⎇, @MRSREF{Representation Naming Strategy⎇,
@MRSREF{PD-STASH⎇, @MRSREF{PD-UNSTASH⎇,
@MRSREF{PD-INDB⎇, @MRSREF{PD-LOOKUP⎇, @MRSREF{PD-ULOOKUP⎇,
@MRSREF{PD-LOOKUPVAL⎇]

@Warnings{
The warnings given for @MRSREF[Discrimination Net] apply here.⎇

@Comment[ @Diagnostics{N/A⎇ ]

@History(RDG, 14 September 1982, created)

@Interactions{
The various connections described in the @i[Interactions] part of @MRSREF[PDT]
apply here, @i[mutatis mutandis].
⎇

@Examples{
The example given for @MRSREF[PDT] works here,
after substituting @T[PD] for @T[PDT],
using a single general discrimination net,
rather than a net associated only with the current theory,
and removing the theory dependencies.
⎇

@sourcefile(DREPN.CL)

@keywords(@MRSIndex[representation], @MRSIndex[discrimination net],
@MRSIndex[general structure], @MRSIndex[theory independent]) 
@END[MRSEntry]
@BEGIN[MRSEntry]@Name(SP)
@Brief(Theory independent, "single" property list based representation.)

@Usage[@T{(⎇REPN <prop-sym> @T{SP)⎇
@T{(SP⎇-<rep'n fn> <prop-sym>@T{)⎇]

@Type(MRS Constant: Representation)

@Descript{
Any <proposition> which is associated with this @T[SP] representation 
will use the SP collection of representation methods --
@BEGIN[Example]
@T[sp-stash] for stashing,
@T[sp-unstash] for unstashing,
@T[sp-lookupval] for term retrieval, and
@T[sp-indb], @T[sp-lookup] and @T[sp-ulookup] for proposition retrieval.
@END[Example]
(The @MRSREF[REPN] entry describes how to associate a proposition
with a representation.)⎇

@BEGIN[MRSSlotContinued]
For notation we will use the generic proposition 
@T[(<Relation> <Arg1> <Arg2>)].
An encoding of this proposition will appear in property list associated
with the first argument, @T[<Arg1>].
This proposition is stored by setting
the @T[<Relation>] property on this property list to the value @T[<Arg2>].
Hence the proposition @T[(Father Mary Fred)] would be encoded by storing
the value @T[Fred] on the @T[Father] property of the atom @T[Mary].

The @MRSREF[Property List] entry mentioned that any
representation based on property lists will
work when dealing with binary propositions.
For these, this encoding is quite efficient, both for storage and retrieval.
However, as it can only access a fact via its second argument,
general retrieval, based on arbitrary matchings, is impossible.

This particular @T[SP] representation further limited to unary functions --
where the value of the @T[<Relation>] and 
@T[<Arg1>] determine a single @T[<Arg2>].
(This is the case for relations like @T[Father],
but not for @T[Neighbor].)@FOOT<
That is, we may want to store the facts that
@T[(Neighbor Palo-Alto Menlo-Park)] and @T[(Neighbor Palo-Alto Mountain-View)];
but cannot do this with this @T[SP] representation
-- as stashing @T[(Neighbor Palo-Alto Mountain-View)] will overwrite
the value of the @T[Neighbor] property of @T[Palo-Alto],
which had been @T[Menlo-Park], with @T[Mountain-View].>
See @MRSREF[MP] for a way of handling these cases.

Note further that this representation does not record the theory dependence of
a given proposition.
This means that once @T[(Father Mary Fred)] has been stashed
(using the SP representation,)
it will remain visible and retrievable even if the current theory 
(i.e. the one active during that stash) has been deactivated.
@END[MRSSlotContinued]

@SeeAlso[
@MRSREF{REPN⎇, @MRSREF{Property List⎇, @MRSREF{Representation Naming Strategy⎇,
@MRSREF[Theories],
@MRSREF{sp-stash⎇, @MRSREF{sp-unstash⎇,
@MRSREF{sp-indb⎇, @MRSREF{sp-lookup⎇, @MRSREF{sp-ulookup⎇,
@MRSREF{sp-lookupval⎇]

@Warnings{
(The warnings given in the @T[Property List] entry apply here.
See also the @i[Description] facet above for further limitations.)
⎇

@Comment[ @Diagnostics{N/A⎇ ]

@History(RDG, 15 September 1982, created.)

@Comment[ @Interactions{N/A⎇ ]

@Examples{
Suppose we have stashed the fact that "the Father of Mary is Fred",
as in the description above.
After this
@T[(sp-lookup ↑(Father Mary Fred))] will return @T[(T)],
similarly @T[(sp-lookup ↑(Father Mary $X))] will return the binding list
@T[(T ($X . Fred))].
(Unless fouled up by some intervening UNSTASH, or STASH.)
However the @T[(sp-lookup ↑(Father $Y Fred))] query will not locate this
@T[(Father Mary Fred)] proposition (and so will probably return @T[NIL],)
as will the @T[(sp-lookup ↑($R Mary Fred))] query.⎇

@sourcefile(DREPN.CL)

@keywords(@MRSIndex[representation],  @MRSIndex[property list],
@MRSIndex[general structure], @MRSIndex[theory independent]) 
@END[MRSEntry]
@BEGIN[MRSEntry]@Name(MP)
@Brief(Theory independent, "multiple-valued" property list based
representation.)

@Usage[@T{(⎇REPN <prop-sym> @T{MP)⎇ or
@T{(MP⎇-<rep'n fn> <prop-sym>@T{)⎇]

@Type(MRS Constant: Representation)

@Descript{
Any <proposition> which is associated with this @T{MP⎇ representation 
will use the MP collection of representation methods --
@BEGIN[Example]
@T[mp-stash] for stashing,
@T[mp-unstash] for unstashing,
@T[mp-lookupval] for term retrieval, and
@T[mp-indb], @T[mp-lookup] and @T[mp-ulookup] for proposition retrieval.
@END[Example]
(The @MRSREF[REPN] entry describes how to associate a proposition
with a representation.)

This representation is very similar to the @MRSREF[SP] one,
but is able to handle arbitrary binary relations
(while SP could only deal with unary functions).

For notation we will use the generic proposition @T[(<Relation> <Arg1> <Arg2>)].
An encoding of this proposition will appear in property list associated
with the first argument, @T[<Arg1>].
This proposition is stored by including
the value @T[<Arg2>] in the @T[<Relation>] property on this property list.
Hence the proposition @T[(Neighbor Palo-Alto Menlo-Park)]
is encoded by adding the value @T[Menlo-Park]
to the value currently found on the @T[Neighbor] property of the atom @T[Palo-Alto].
After asserting @T[(Neighbor Palo-Alto Mountain-View)] the value
of the @T[Neighbor] property of @T[Palo-Alto] will be
@T[(Menlo-Park Mountain-View)].

The @MRSREF[Property List] entry mentioned that any representation
based on property lists will work when dealing with binary propositions.
For these, this encoding is quite efficient, both for storage and retrieval.
However, it can only access a fact via its second argument.
General retrieval, based on arbitrary matchings, is impossible.

Unlike SP,
this MP representation is not limited to unary functions.
Like SP,
MP does not record the theory dependence of a given proposition.
This means that once @T[(Father Mary Fred)] has been stashed
(using the MP representation,)
it will remain visible and retrievable even if the current theory 
(i.e. the one active during that stash) has been deactivated.
⎇

@SeeAlso[
@MRSREF{REPN⎇, @MRSREF{Property List⎇, @MRSREF{Representation Naming Strategy⎇,
@MRSREF{Theories⎇,
@MRSREF{mp-stash⎇, @MRSREF{mp-unstash⎇,
@MRSREF{mp-indb⎇, @MRSREF{mp-lookup⎇, @MRSREF{mp-ulookup⎇,
@MRSREF{mp-lookupval⎇]
]

@Warnings{
(The warnings given in the @T[Property List] entry apply here.
See also the @i[Description] facet above for further limitations.)
⎇

@Comment[ @Diagnostics{N/A⎇ ]

@History(RDG, 15 September 1982, created.)

@Comment[ @Interactions{N/A⎇ ]

@Examples{
(The Example found in @T[SP] is relevant here.)
⎇

@sourcefile(MPREPN)

@keywords(@MRSIndex[representation],  @MRSIndex[property list],
@MRSIndex[non-functional relation],
@MRSIndex[general structure], @MRSIndex[theory independent]) 
@END[MRSEntry]
@INCLUDE[RPNPRC.MSS]
@Comment{ That retrieves the needed descriptions of the actual
lisp procedures. ⎇